Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Respect variable type ascription when initializer has type Never #6911

Merged
merged 13 commits into from
Feb 12, 2025

Conversation

jjcnn
Copy link
Contributor

@jjcnn jjcnn commented Feb 10, 2025

Description

Fixes #6391.

This PR fixes an issue with variable declarations whose initializers diverge because they contain return, continue or break expressions. In this case the initializer typechecks to Never, and the variable is inferred to have type Never in the subsequent (unreachable) code:

let mut x = return;
x = 42; // Illegal, since x has type Never

The problem is that this is the case even when the variable declaration has a type ascription:

let mut x : u32 = return;
x = 42; // Should be legal, since x has the type ascription u32

As part of the fix there is another slight change of behavior for code blocks that diverge. Until now the type of a code block has been determined based on whether it contains a diverging expression:

match { return; true } // Considered to have type Never because of `return;`
{ 
   // Type Never does not have a constructor
}

We now determine the type of a code block based on its implicit return:

match { return; true }
{
    // Type Boolean has two constructors
    true => ...,
    false => ...,
}

In principle this is a breaking change, but the only change in behavior is in code blocks that contain a return, break or continue, and then contains dead code after that expression, so I can't imagine anyone will be affected by it.

Checklist

  • I have linked to any relevant issues.
  • I have commented my code, particularly in hard-to-understand areas.
  • I have updated the documentation where relevant (API docs, the reference, and the Sway book).
  • I have added tests that prove my fix is effective or that my feature works.
  • I have added (or requested a maintainer to add) the necessary Breaking* or New Feature labels where relevant.
  • I have done my best to ensure that my PR adheres to the Fuel Labs Code Review Standards.
  • I have requested a review from the relevant team or maintainers.

Copy link

codspeed-hq bot commented Feb 10, 2025

CodSpeed Performance Report

Merging #6911 will not alter performance

Comparing jjcnn/unify_never (e44b0bb) with master (ac95d2d)

Summary

✅ 22 untouched benchmarks

@jjcnn jjcnn requested a review from ironcev February 10, 2025 22:33
@jjcnn jjcnn self-assigned this Feb 10, 2025
@jjcnn jjcnn marked this pull request as ready for review February 10, 2025 22:33
@jjcnn jjcnn requested a review from a team as a code owner February 10, 2025 22:33
@jjcnn jjcnn added the team:compiler Compiler Team label Feb 10, 2025
IGI-111
IGI-111 previously approved these changes Feb 11, 2025
@tritao tritao merged commit 8788257 into master Feb 12, 2025
41 checks passed
@tritao tritao deleted the jjcnn/unify_never branch February 12, 2025 22:52
@jjcnn jjcnn mentioned this pull request Feb 20, 2025
8 tasks
tritao pushed a commit that referenced this pull request Feb 20, 2025
## Description

Shows that #6387 has been fixed.

This PR adds a few tests of variable initializers that involve type
Never. In this case the variable's type ascription should be used
instead of the initializer's type.

No changes have been made to the compiler, since the problem that was
originally reported was fixed by #6911.


## Checklist

- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
@jjcnn jjcnn mentioned this pull request Feb 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
team:compiler Compiler Team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Unification of Never Type
4 participants